The dependability of mobile devices is directly linked to the maintenance cost of such devices. An unreliable device (e.g., one with exceptionally large amount of bugs in its software stack) may result in expensive costs to device service operators in customer service calls and/or device recalls.
A major cause of dependability concern on mobile devices is in device management (DM) operations conducted on such device. DM operations include operations to install/remove applications/libraries, update applications/libraries, as well as changing system and application settings.
Typically, at the time just after the user purchased the mobile device, the device is considered quite dependable as the device model had typically gone through rigorous testing/tuning by the device manufacturer, the software developers, and/or the service operator. Thus, as long as the user uses the device in a way expected by manufacturers and software developers, and not change the device to a state not anticipated by manufacturers and software developers, the software on the device should likely continue to function reliably.
However, as the user starts to conduct more and more DM operations, the state of the device deviates further and further from expected/normal states. Such deviated states may make the device unreliable and increase device maintenance costs for the operator. The risk of a device ending into problematic states is increasing with the user having more freedom to conduct DM operations (such as downloading and installing suspicious native applications) and with the software stack on the device becoming more and more complex.
Users of open computing platforms are more likely to find themselves in situations like “The application just crashed! But yester it was fine!”, or “why this game runs great on his device but doesn't work on mine?!” In open computing platforms, users can extensively change the configurations of the hardware and software, including introducing new hardware and software into the platforms. Increasingly, personal computing systems are becoming open computing platforms, including the majority of PCs, as well as an increasing number of mobile devices, such as PDSs and cell phones.
The above described frustrating dependability related scenarios are more likely to happen on open computing platforms because such platforms are more suspicious to problematic configuration changes. For example, assigning wrong value to a configuration item (such as a port number) may cause problem for software that uses the configuration items. As another example, updating a library during the course of installing a new application may break old applications that depend on the library, if the new version of the library is not backward compatible.
Traditional approaches for diagnosing and solving such configuration problems involves first describing the symptoms of the problem, then from a problem database, matching described symptoms with a number of records, and matching described symptoms with a number of records, and finally, for each record, if the record indicates that the cause of the problem is a configuration item, then try to set the configuration item with suggested value. The process involves a large amount of human involvement, and taxes heavy cost for companies providing such customer services.
To reduce human involvement and other costs in the process, researchers have looked at approaches for automatically generating a list of suspected problematic configurations, approaches for ranking such suspects, and approaches for automatically recovering from misconfiguration. Such existing efforts typically use the information that the value of a configuration item was changed to identify suspect configuration items. A limitation of such a binary approach (i.e., the value was changes or not) is that, when the number of items that has changed is big, it is difficult to nail down the misconfigurated items(s).
The use of correctness constraints on configuration classes has been proposed. A configuration class is defined as a group of Windows hierarchical registry keys with the same structure. A registry key violating any of the constraints of its configuration class is considered as possible misconfiguration. Four types of constraints are used: size constraint, which says that a subkey in a given configuration class has a fixed size; value constraint, which says that the value of a subkey in a given configuration class takes on one of a small set values; reference constraints, which says that a registry key should always reference instance of a particular configuration class; and equality constraint, which says that a group of registry keys should always have the same value.